home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1084 < prev    next >
Text File  |  1994-08-27  |  6KB  |  167 lines
  1. Subject: app_defs
  2. Date: Thu, 28 Jul 1994 12:01:59 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7. Ofir:
  8. >[re: other attributes than shortcuts in the app_defs file]
  9. >
  10. >I think the best thing is to do a stage at a time. It's fine setting
  11. >zillions of standards, it's another thing getting them implemented. The
  12. >more we do the less support we get.
  13. >
  14. >The first app-defs file should only deal with keyboard shortcuts. The
  15. >file format should be open so that we could add more things at a later
  16. >stage.
  17.  
  18. Choices we make for the names of attributes in the app_defs file don't
  19. require any implementation:  they're just choices so as to have commonality
  20. for any apps that want the same attributes.  It's like choosing a cookie:
  21. doesn't really matter what it is, provided everyone knows.
  22.  
  23.  
  24. Summary of the issues I can think of:
  25.  
  26.     1. Format (eg. see below)
  27.     2. Significance of order of entries (eg. does later override former?)
  28.     3. Location (eg. C:\SYSTEM)
  29.     4. Attribute names (eg. keyOpen? shortcutOpen? etc.)
  30.     5. Value representations (eg. ^C? Ctrl-C? Shift-X? 0x6643?)
  31.     6. Attributes other than shortcuts.
  32.  
  33. Inlike the short-cuts file, I think we should be able to come to agreement
  34. pretty easily on this, as (1) it is fairly simple to implement (2) there is
  35. no real existing standard [do we count assign.sys :)] (3) it doesn't involve
  36. many concerns for the user [as Ofir said - many of them will never touch it].
  37.  
  38.  
  39. Re the format,
  40.  
  41. It may be useful to have a `type' code for each atrribute-value pair in
  42. the app_defs.sys file, to facilitate editing via a tool.  For example:
  43.  
  44.  
  45. *.papyrus*.key.openFile: KEY = ^O
  46. *.papyrus*.font:         FNT = Gemini 10pt
  47. *.papyrus*.key.newFile:  KEY = 0x00380402=F1   // Pretend this is the F1 code
  48. *.papyrus*.fgColor*:     COL = Purple
  49. *.papyrus*.bgColor*:     COL = 0x00150315   // Pretend this is a nice colour
  50. *.tempFile*:             FIL = f:\tmp
  51. *.foo.name*:             TXT = Hello World
  52.  
  53. <attribute-pattern> ":" <type> "=" <value>
  54.  
  55. Anyone not like the ":" and "="?  They're redundant anyway:
  56.  
  57. <attribute-pattern-no-spaces> <whitespace> <type-no-space> <value>
  58.  
  59. The type need not be 3 characters.
  60.  
  61. A app_defs.sys editing tool could then know how what to do with ALL
  62. lines as far as allowing the user to edit them.  It also helps the user
  63. to know what they can put for an option.  Applications reading the
  64. app_defs.sys file could either ignore the type, or just check that it
  65. is as expected.  Only one type should be allowed for each attribute,
  66. but different forms of representing the value of that type in text may
  67. be allowed (such as the text "^O" and the scancode+menuname "0x00380402=F1").
  68. All apps should support the same conversions from value text to actual
  69. value, so the choices should be kept pretty small.  
  70.  
  71. The format of an attribute could be:
  72.  
  73. <application-type>.<application-name>.{<window>|<other qualifier>}.<name>
  74.  
  75. It doesn't really matter what the format is, as all an application needs
  76. to do is a wildcard match against it.
  77.  
  78. Standard application-types could be:
  79.  
  80.     word
  81.     image
  82.     dtp
  83.     util
  84.     game
  85.  
  86. The purpose of the application-type is to allow class-wide attributes,
  87. such as:
  88.  
  89. game.*.hog_cpu: true
  90.  
  91. It's just an option - I'm not dead-set on the idea, but it costs us nothing,
  92. since we can just pattern-match anyway.
  93.  
  94. David Oakley:
  95. >For keys, I think we need to formalise as many keys as are used in a wide 
  96. >number of applications. This means all of the keys that Atari/GemList 
  97. >specify, plus a few more if we can think of them.
  98.  
  99. That's a good idea.  If only to define the names of the attributes. eg, I
  100. might have:
  101.  
  102. *.nethack*.key.saveAndQuit: Shift-S
  103.  
  104. But I don't expect us to make a `standard default' for saveAndQuit.
  105. There are many others.  Basically, we can just take a look at all the
  106. menu items in all the programs we have and divide them into 4 groups:
  107.  
  108.     1. standard (eg. Open)
  109.     2. not standard (eg. Load)
  110.     3. common (eg. Goto Mark)
  111.     4. not common (eg. Offer Corpse To God)
  112.  
  113. (1) and (3) should have names chosen for them.
  114. (1) should have standard defaults decided for them (which we've almost done).
  115. (2) should be listed in gemlist docs as Do Not Use, along with proper term.
  116. (4) can be ignored.
  117.  
  118. >Dialogs in Windows (on/off)
  119. >Novice User Help (on/off)
  120. >Confirm on Exit/Save on Exit
  121. >Default Window Size
  122.  
  123. Here's some *possibilities* (not sure they're that useful):
  124.  
  125. WindowGadgets (MOVER|...)
  126. WindowGeometry 80x25+10+10
  127. SizingProtocol (click-move-click / drag)
  128. MovingProtocol (click-move-click / drag)
  129. PopupProtocol (pop-up / drop-down / ...)
  130. User.Handedness (left / right)  // Hey!  It' might be useful :)
  131. Keyboard Focus (mouse/top/click)  Ouch, Ofir, stop hitting me!  Ouch!  Oooof.
  132.  (just to give it a standard name - I'm not saying people should use it,
  133.   just that if they do, this is how it is enabled)
  134.  
  135. >Auto Save Prefs on Exit
  136.  
  137. This is an interesting one.  Will there BE any `preferences' dialog, once
  138. we have an app_defs.sys file and a GUI for editing it?  Some of the issues
  139. are:  do you want to set window positions outside the application?  should
  140. an application modify the app_defs.sys file on a `save preferences' operation?
  141.  
  142. Note that the above can still all be configured on a per-application basis,
  143. so even if you generally hate `Confirm on Exit', there might be a couple of
  144. applications for which you enable it.
  145.  
  146.  
  147.  
  148. BTW, I volunteer to make an app_defs.sys editor. (of course, it will be 500K ;)
  149.  
  150. chrisridd:
  151. >What we *should* be doing, IMHO, is proposing and voting for the
  152. >existence of a shortcut file or files, and only then discussing the
  153. >precise contents of it. The whole voting period should be much shorter
  154. >too, as this list is very active :-) Say two weeks per vote.
  155.  
  156. Voting before discussion?  That's not very democratic.  It's like voting
  157. for a parliament, THEN letting them discuss policy.
  158.  
  159. I've certainly changed my mind about a lot of things since listenning
  160. to the other list subscribers.  Preclude discussion and you end up with
  161. the type of standards comittees you often get in industry:  where
  162. everyone is just trying to make THEIR PRODUCT the standard, regardless
  163. of its merits.
  164.  
  165. --
  166. Warwick
  167.